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METHODS AND SYSTEMS FOR EFFECTING PAYMENT. CARD 
TRANSACTIONS 

Field of the Invention 

The present invention relates to card payment systems. In particular, the present 
invention relates to systems and methods for processing payment card transactions in a 
dynamic currency conversion and/or multi-currency scheme. 

Background to the Invention 

Several types of card payment systems are available, examples of which include 
credit cards, charge cards and debit cards. In general, transactions involving a card 
payment are conducted in the currency of the merchant. Thus, if an Irish credit card is 
used for a purchase in the USA, the currency of the transaction will probably be in US$. 
Hie transaction value will subsequently be converted into an equivalent EURO value by 
the credit card holder's bank but is unknown at the point of sale. This equivalent EURO 
value will subsequently appear on the credit card holder's statement. This restriction can 
be inconvenient for cardholders travelling abroad, as they are unsure of the exact value 
of the transaction in their own currency at the point and time of sale. 

Dynamic currency conversion overcomes these limitations by performing the 
currency conversion at the point of sale at the time the customer makes a purchase using 
their payment card. An example of a dynamic currency conversion system is described 
in WO01/0486. With dynamic currency conversion processes, the cardholder is 
informed at the point of purchase as to what amount they are paying in the cardholder's 
own currency, whilst the merchant obtains payment in the merchant's own currency. 
This process is possible because the function of converting from the currency of the 
merchant to the currency of the cardholder is performed at the point of sale terminal 
rather than in the computer systems of the bank in which the cardholder has their credit 



card account. In the context of the present application, the term bank refers generally to 
any financial institution, which offers payment card services and may be taken to 
include, for example, building societies and credit unions. 

In addition. to dynamic currency conversion schemes, multi currency schemes 
also operate to perform the currency conversion part of the transaction prior to 
submitting the transaction records to the banks for processing. However, in a multi 
currency scheme the conversion process does not necessarily take place at the point or 
time of sale but is. converted subsequently. 

Payment card transactions are processed and submitted from the merchants to 
the financial institutions, or an intermediary, as transaction records. Each transaction has 
an associated transaction record, containing the details of the transaction. Before the 
introduction of dynamic currency conversion in payment card transactions, an extract of 
a transaction record would have looked something along the lines of the transaction 
"AO" shown in Figure 1. 

The precise fields and formats of fields used may vary from bank to bank. In 
brief, the data in the fields identifies the date of the transaction, the name of the holder 
of the payment card, the card number of the payment card, the expiry date of the 
payment card, the name of the merchant who is performing the transaction, the code of 
the merchant performing the transaction and the amount of the transaction. 

With the introduction of dynamic currency conversion transactions, a number of 
additional-fields are required to be "captured". An extract of an exemplary transaction 
record in a dynamic currency conversion environment is shown in the transaction "BO" 
in figure 2. The additional fields to be captured comprise the converted currency 
element of the transaction, which may include the converted amount in the currency of 
the cardholder's payment card account, which the cardholder will see on their statement 
and the exchange rate used to perform the conversion. The currency of the cardholder 
may also be required. 



Normal transactions (transactions processed in the currency of the merchant 
only, an example of which is shown in figure 1) are processed conventionally typically 
through the acquiring bank of the merchant, whereas the dynamic currency conversion 
transactions may be separated from the normal transactions and may be routed to a 
dynamic currency conversion system , which may be separate from the acquiring bank, 
for transmission into the card schemes and which may be settled back to the acquiring 
bank and/or the merchant via a multi-currency payment card processing bank or other 
route. A multi-currency payment card processing bank is a bank which is capable of 
processing payment card transactions from merchants in more than one currency. The 
separation function may be handled by a POS device dispatching normal and/or 
converted transactions to a first host and normal and/or converted transactions to 
another host or hosts. The separation function may also be performed before the POS 
device, at the POS device and/or post the POS device by an acquirer and/or 3 rd party 
host, server or switch service and/or any other suitable separation means. 

For the purposes of the Acquirer and/or other third parties paying the merchant 
and/or providing the Merchant with the statement in relation to all merchant transactions 
(rather than two separate regular payments and/or two separate statements), the normal 
and dynamic currency conversion transactions need to be amalgamated in some way. 
Accordingly, for settlement purposes vis a vis the acquirer to the merchant, and likewise 
the statement from the acquirer to the merchant and/or for related card scheme merchant 
service fee charges deducted & payable to the acquirer by the merchant, a "ghost copy" 
of the dynamic currency conversion transactions may be incorporated/sent to the 
Acquirer's or other third parties host. However, to prevent duplication of debits against 
the Card Holder, these "ghost copy" transactions must not be processed into the card 
schemes with the normal transactions: Thus the Acquirer's and/or third parties host 
systems have to be amended, in addition to modifications to the related accounting 
thereof. 

This presents a significant difficulty for acquiring banks interested, in using 
dynamic currency conversion services, as the acquiring banks have to amend their 
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computer systems to deal with the splitting/amalgamation for the purposes of providing 
a statement to the merchant and payment/settlement to the merchant. To facilitate 
dynamic currency conversion services, a significant amount of computer code is 
required to be re-written on the banks' computer systems. 
5 • " 

Accordingly, although it appears that a significant number of banks would like 
to offer dynamic currency conversion payment card facilities, the diversion of computer 
resources which are frequently scarce and in several cases must be booked years in 
advance makes the proposition unattractive. Furthermore, the necessity of having to 
10 interfere with existing bank computer IT systems/procedures is something that banks are 
extremely reluctant to risk. 

This situation is to be contrasted to the position regarding the software on the 
payment card tenninals located at the merchant locations or even at an intermediate 
15 host,. where it is relatively easy to have independent resources allocated to amend the 

software in the payment card terminals or an intermediate host. Any changes to software 
in either the payment card terminals or at an intermediate host are unlikely to interfere 
with the operation of the acquiring bank's host computer. 

20 Accordingly, it is an object of the present invention to provide a method to effect 

the performance of a converted payment card transaction, which obviates the necessity 
for changes to the acquiring banks' host computer system . 

25 Summary of the Invention 

Accordingly, a first embodiment of the invention provides a method for effecting 
the performance of a payment card transaction for a first transaction amount in a first 
currency, between a first merchant and a first payment card holder, the method 
30 comprising the steps of: 

a) creating a first payment card transaction record between the first merchant and a 
second cardholder for the first transaction amount, ■ 



b) creating a second payment card transaction record between a second merchant and 
the first cardholder, wherein the second transaction record identifies a second 
transaction amount in a second currency which equates to the first transaction amount 
converted into the second currency, and 

c) submitting the first transaction record and the second transaction record for 
processing as payment card transactions. 

As the first cardholder is effectively replaced by a second cardholder in the first 
transaction record, the subsequent processing of the second transaction by a dynamic 
currency conversion operator will not cause a double debit in respect of the first 
cardholder. Thus the necessity of re-writing an acquirer's software to avoid any such 
related type double debit is avoided. Similarly, from the perspective of the acquirer 
and/or its merchant handling of transactions processed for the merchant, the acquirer, 
systems do not have to be amended to introduce and/or receive ghost transactions for the 
purposes of amalgamation and/or calculating service charges for the merchant. 

The second cardholder may be associated with the second merchant. 

The step of submitting the first transaction record and the second transaction ' 
r record for processing may comprise the step of submitting the first transaction record for 
processing as an unconverted payment transaction. The step of submitting the first 
transaction record and the second transaction record for processing may comprise the 
step of submitting the second transaction record for processing as a converted payment 
transaction. 

Optionally, the invention may comprise the additional steps of creating a third 
payment card transaction record between the second cardholder and the second 
merchant for an amount in the first currency, which is the negative equivalent of the first 
amount and submitting the third transaction for payment processing. The third 
transaction may be submitted as an unconverted payment card transaction. 



The advantage of this third transaction record is that it effectively cancels out the 
first transaction record vis a vis the second cardholder. Thus there is no need to correct 
the balances on the account of the second cardholder. 

The method may comprise the initial step of determining whether a transaction is 
a dynamic currency convertible transaction prior to performing the steps of creating the 
one or more transaction records. 

The method may comprise the initial step of receiving an indication of a 
payment card transaction for a first transaction amount in a first currency between a first 
merchant and a first payment card holder. 

The method may comprise the step of posting the first and/or second and/or third 
transactions to the computer system associated with an acquiring bank. 

The invention also provides a system adapted to effect the performance of a 
payment card transaction, the system comprising 

mean's for receiving details of a transaction for a first transaction amount in a first 
currency, between a first merchant and a first payment card holder, 
means for creating a first payment card transaction record between the first merchant 
and a second cardholder for the first transaction amount, 

means for creating a second payment card transaction record between a second merchant 
and the first cardholder, wherein the second transaction record identifies a second 
transaction amount in a second currency which equates to the first transaction amount 
converted into the second currency, and 

means for submitting created transaction records to a host for processing as. payment 
card transactions. 

The means for submitting created transaction records may be suitably adapted to 
submit the first transaction record for processing as an unconverted payment transaction. 
The means for submitting created transaction records: may be suitably adapted to submit 
the second transaction record for processing as a converted payment transaction. 



Optionally, the system may comprise means for creating a third payment card 
transaction record between the second cardholder and the second merchant for an 
amount in the first currency, which is the negative equivalent of the first amount and 
submitting the third transaction for payment processing. The means for submitting 
created transaction records may be suitably adapted to submit the third transaction 
record for processing as an unconverted payment transaction. 

The system may comprise means for detemiining whether a transaction is a 
dynamic currency convertible transaction prior to performing the steps of creating the 
one or more transaction records. 

In one embodiment the system comprises a payment card terminal. In this 
embodiment, the means for receiving details of the transaction for a first transaction 
amount in a first currency comprises the data entry means of the terminal, including for 
example smart card readers, magnetic strip readers and keypads. The means for 
receiving details may include means for retrieving the details of the merchant from the 
terminal memory. In a terminal, the means for creating the first and second payment 
transaction records may be implemented using appropriate software routines. The details 
for the second merchant and cardholder are suitably stored in the terminal memory and 
retrieved by the means for creating the first and second payment transaction records as 
required. 

In one embodiment the system comprises an intermediate host computer system 
adapted to receive payment transaction records from a payment card terminal or other 
device and route them for processing as either converted or unconverted transactions. In 
this embodiment, the means for receiving details of the transaction comprises means for 
receiving transaction records. The means for creating the first payment card transaction 
record and the means for creating the second payment card transaction may be 
implemented as software routines. The host may be an acquirer's host, a multi-currency 
bank's host, an intermediate host or any other host. Moreover an acquirer and/or a • 
. multi-currency bank may begone and the same person or entirely separate, i.e. in the._ 
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acquirer and multi-currency (and/or its/their host) may be one entity, two independent 
entities within the same bank or two separate banks. 

Brief Description of the Drawings 

5 

The invention will now be described in greater detail with reference to the 
accompanying drawings in which: 

Figure 1 is an example of a transaction record according to the prior art, 
Figure 2 is an example of a second transaction record known from the prior art, 
10 Figure 3 is a block diagram representation of a system suitable for implementing the 
present invention, 

Figure 4 is a flowchart of a method according to the present invention, 
Figure 5 is an example of a first transaction according to the present invention, 
, Figure 6 is an example of a second transaction according to the present invention, and 
15 Figure 7 is an example of a third transaction according to the present invention. 



Detailed Description of the Drawings 

20 The present invention is intended for use within a card payment system, and in 

particular for use with converted transactions. An exemplary scheme, illustrated in 
Figure 3, comprises a number of POS (point of sale) terminal devices 1 . The Teixninal 
devices 1 are adapted to perform payment card transactions. Each device is associated 
with a merchant. In the exemplary configuration shown, an intermediate host 2 acts as 

25 an interface between the POS devices and the payment processing systems of the banks 
and currency conversion schemes. 

Payment card transactions are conventionally initiated by a cardholder 
presenting a payment card at the point of sale at the time of making a purchase. The 
30 merchant operating the POS device conventionally swipes the payment card through a 
magnetic strip reader.x>n a POS device, and then enters the. amount of the transaction 
using a keypad. Other methods of performing card transactions, e.g. by telephone or the 
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Internet, are well known in the art. The exact manner of entering the payment card 
details and the transaction details are unimportant in the context of the present 
invention. 



5 , The individual payment card transactions may be either a conventional 

(unconverted) transaction or a converted transaction. In a conventional transaction, the 
transaction is performed in the currency of the merchant. In a conventional transaction, 
if the cardholder's account operates in a different currency to that of the merchant, the 
cardholder's bank performs a conversion into the currency of the cardholder's account at 
10 the time of posting the transaction to their account. This conversion generally takes 
place some time, even days, after the initial transaction has been completed. 

Conventional transactions are to be contrasted to converted transactions, where 
the transaction amount is converted into the currency of the cardholder's payment card 
15 account prior to submission of the transaction fo the banks for processing. An example 
. of a converted transaction is a dynamic.currency converted transaction. An example of a 
dynamic currency conversion system is described in WO01/0486. 

In the exemplary scheme shown, each of the POS devices 1 is adapted to handle 
20 conventional and/or converted payment card transactions. For each transaction 
conducted on a POS device, a transaction record is created and stored on the POS 
. device. 

An exemplary conventional transaction record 100 is shown in figure 1. The 
25 transaction record identifies the date of the transaction 3, the name of the cardholder 4, 
the card number of the cardholder 5, the expiry date of the card 6, the name of the 
merchant 7, the merchant code 8 and the transaction amount 9. The transaction record 
may include other information and fields. 

30 An exemplary converted transaction 200 is shown in figure 2. Fields that are the 

same as those .fields described previously for a conventional transaction are given the 
same reference numerals. The converted transaction has a number of fields 
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corresponding to the fields contained in a conventional transaction, such, as the name of 
the cardholder 4, the card number of the cardholder 5, the expiry date of the card 6, the 
name of the merchant 7, the merchant code 8 and the transaction amount 9 etc. 

5 The converted transaction record may also include other information and fields 

present in conventional transaction records. In addition, to these fields the converted 
transaction record contains data in a number of additional fields, which identify the 
transaction as being a converted transaction. These fields may include a field to store the 
transaction amount in the currency of the cardholder 11 and/or a field to store the 
10 exchange rate used in the conversion 10. Other fields that may be provided include a 
currency identifier field for identifying the currency of the cardholder. 

It will be appreciated that the same field structure may be used for converted and 
unconverted transactions with an identifier or other means used to distinguish between 
15 the two types of transaction. For example, a conventional transaction could be 

distinguished from a converted transaction by the absence of data (or the presence of 
null values) in fields relating to converted transactions, e.g. the converted amount field 
or exchange rate .field. 

20 The individual transaction records are uploaded to the intermediate host 2, for 

example as a batch process at the end of each day or at any time during or at the end of . 
the transaction creation and capture cycle. 

To facilitate the uploading of transaction records, the POS devices 1 are suitably 
25 adapted to communicate with the intermediate host using appropriate communication 
means; typically by modem over a telephone line. 

The intermediate host 2 is adapted to receive the transaction records from the 
POS devices 1 and to process. The intermediate host 2 subsequently forwards the 
30 transaction records onto the computer systems associated with acquiring banks, which 
are ultimately responsible for the processing of the payment card transactions. 



m 
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Upon receipt of the individual transaction records, the intermediate host 2 may 
perform some checks and verification routines to ensure the accuracy of the records 
submitted. The intermediate host 2 may then separate the converted transactions from 
the conventional transactions. The conventional transactions are forwarded for 
processing in accordance with the methods of the prior art to the merchant's acquiring 
bank 12, which in turn forwards the transaction to the payment card schemes 13. The 
card payment schemes 13 ensure that the correct charges are applied to appropriate 
cardholders' accounts. 



In the prior art, the converted transactions were forwarded directly to the 
currency conversion scheme 14 or an associate of the currency conversion scheme to 
facilitate transactions to be processed through a multi-currency bank 15 . The multi- 
• currency bank 15 in turn forwards the transactions to the payment card schemes 13, who 
15 in turn apply the charges to appropriate cardholder's accounts. 

In the present invention, an exemplary implementation of which is shown in 
Figure 4, a number of new transaction records are created from each convertible 
transaction record generated from a'POS device, and at least one of these new 
20 . transaction records is submitted for processing to the merchant's acquiring bank. 

The exemplary method, illustrated in Figure 4, will now be described with 
reference to the exemplary converted transaction record 200 shown in Figure, 2, which 
identifies a record for a converted payment card transaction between a merchant and a 
25 cardholder for an amount. This converted payment card transaction record may be 
received by a hpst from the POS device of the merchant. 

Once the convertible payment card transaction record is received by a host 400, 
the host commences generating a number of payment transaction records. ■ 



In particular, a first transaction record is created 401 between the merchant and 
a second cardholder for the same amount as the received transaction record. This first 
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transaction record identifies an. unconverted transaction between the merchant and a 
second cardholder. An exemplary resulting first transaction record 500 is shown in 
Figure 5. This newly created first transaction record may be created by amending the 
received record. 

The second cardholder identified in the first transaction record 500 is a 
cardholder account or pseudo cardholder of an intermediary possibly for example the 
operator or an associate of the operator of the currency conversion scheme. 

Thus the resulting transaction created, effectively creates a debit from the 
intermediary cardholder to the merchant. This first transaction may subsequently be 
submitted to the acquiring bank 12 of the merchant for payment processing in the same 
way as the conventional (unconverted) transaction records. A record will thus exist in 
the acquiring bank 12 of the merchant showing a credit to the merchant's account. This 
credit will appear as a conventional payment card- transaction between the merchant and 
a second cardholder (which in the present example is the operator or an associate thereof 
of the currency conversion scheme). 

Accordingly, charges, reports and calculations for the merchant may be 
performed without any requirement for alteration of the software of the acquiring banks 
or the posting and subsequent removing or "fixing" of ghost transactions. 

In addition, to the creation of the first transaction record 500, a host creates 402 a 
second transaction record, illustrated for example in Figure 6. This second transaction 
record 600 identifies a transaction between a second merchant and the first cardholder. 
In the present example, the second merchant is a merchant account associated with the 
intermediary, which may for example be the operator or an associate of the operator of 
the currency conversion scheme. The second transaction record 600 is a converted 
transaction record and thus contains a second transaction amount in a second currency 
(that of the cardholder) equating to the first transaction amount converted into the 
second currency. Thus, a payment card transaction is effectively created which credits 
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an intermediary or pseu.do merchant, possibly, for example, an operator or an associate 
of the operator of the currency conversion scheme, and debits the cardholder. 

This second transaction record 600 may be submitted for payment processing, as 
5 in the prior art, to the currency conversion scheme 14 for onward submission via a 
multi-currency bank 15 and subsequently the card schemes 13. 

As the cardholder is effectively replaced by a second (intermediary) cardholder 
in the first transaction record, the subsequent processing of the second transaction by a 

10 dynamic currency conversion will not cause a double debit in respect of the first 

cardholder. Thus the necessity of re-writing an acquirer's software to avoid any such 
related double debit is avoided. Similarly, from the perspective of the acquirer and/or its 
merchant handling of transactions processed for the merchant, the acquirer systems do 
not have to be amended to introduce, cater and/or receive ghost transactions for the 

15 . purposes of amalgamation and/or calculating service charges for the merchant. 

The above described method in effect creates two transactions, the net result of 
which is a debit from the cardholder and a credit to the merchant, with a third party 
acting as an intermediary and having a merchant account and a cardholder account. 

20 

It will be appreciated that the merchant account of the intermediary will 
accumulate funds (credit), whilst the cardholder account of the intermediary will be 
debited. To prevent inconsistencies arising in the operation of the acquiring banks 
systems, it may be necessary to offset the balances in the intermediary's merchant 
25 account against those in the intermediaries cardholder account. This could for example 
be implemented using a daily transfer from the intermediary's merchant account to the 
intermediary's cardholder account. Such a transfer could be implemented at the end of 
each day for the outstanding account balance as a payment card transaction between the 
intermediaries cardholder and the intermediaries merchant account, in effect a refund. 



30 



Another approach is to effectively perform a transfer between the intermediary's 
merchant account and the intermediary's cardholder account for each converted 
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transaction. Thus, in addition, to the creation of the two transaction records described 
above, a third transaction 700 may be created 403 as shown by example in Figure 7. 
This transaction represents a conventional payment card transaction between the 
intermediary's merchant account and the intermediary's cardholder account. This third 
5 transaction 700 may be submitted, for example to the merchant's acquiring bank for 
processing 404. 



10 Although the present invention has been described with reference to an 

intermediate host, it will be appreciated that the crux of the present invention is the 
conversion of a single payment card transaction into two separate payment card 
transactions using an intermediary as the join between the two separate transactions. It 
will further be appreciated that this concept may be applied in a number of different 

•15 ways to achieve the desired end result. For example, the splitting into two transactions 
may be performed at the POS terminal, the intermediate or other host or any 
.combination thereof. 

The words "comprises/comprising" and the words "having/including" when 
20 used herein with reference to the present invention are used to specify the. presence of 
stated features, integers, steps or components but does not preclude the presence or 
addition of one or more other features, integers, steps, components or groups thereof. 



Claims 
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1 . A method for effecting the performance of a payment card transaction for a first 
transaction amount in a first currency, between a first merchant and a first payment 
card holder, the method comprising the steps of: 

a) creating a first payment card transaction record between the first merchant and a 
second cardholder for the first transaction amount, 

b) creating a second payment card transaction record between a second merchant and 
the first cardholder, wherein the second transaction record identifies a second 
transaction amount in a second currency which equates to the first transaction amount 
converted into the second currency, and 

c) submitting the first transaction record and the second transaction record for 
processing as payment card transactions . 

2. A method for effecting the performance of a payment card transaction-according 
to claim 1, wherein the step of submitting the first transaction record and the second 
transaction record for processing comprises the step of submitting the first 
transaction record for processing as an unconverted payment transaction. 

3. A method for effecting the performance of a payment card transaction according to 
claim 1 or claim 2, wherein the step of submitting the first transaction record and the 
second transaction record for processing comprises the step of submitting the second 
transaction record for processing as a converted payment transaction. 

4. A method for effecting the performance of a payment card transaction according to 
any preceding claim, further comprising the steps of creating a third payment card 
transaction record between the second cardholder and the second merchant for an 
amount in the first currency, which is the negative equivalent of the first amount and 
submitting the third transaction for payment processing. 
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5 . A method for effecting the performance of a payment card transaction according to 
claim 4, wherein the third transaction is submitted as an unconverted payment card 
transaction. 

6 . A method for effecting the performance of a payment card transaction according to 
any preceding claim, further comprising the initial step of determining whether a 
transaction is a dynamic currency convertible transaction prior to performing the steps 
of creating the one or more transaction records. 

7. A method for effecting the performance of a payment card transaction according to 
any preceding claim, further comprising the step of posting the first and/or second 
and/or third transactions to the host computer system associated with an acquiring 
and/or multi-currency bank. 

8 . A system adapted to-effect the pes* ormance of a payment card transaction, the 
system comprising: 

means for receiving details of a transaction for a first transaction amount in a first 
currency, between a first merchant and a first payment card holder, 
means for creating a first payment card transaction record between the first merchant 
and a second cardholder for the first transaction amount, means for creating a second 
payment card transaction record between a second merchant and the first cardholder, 
wherein the second transaction record identifies a second transaction amount in a second 
currency which equates to the first transaction amount converted into the second 
currency, and 

means for submitting created transaction records to a host for processing as payment . 
card transactions. 

9. A system adapted to effect the performance of a payment card transaction according 
to claim 8, wherein the means for submitting created transaction records is suitably 
adapted to submit the first transaction record for processing as an unconverted payment 
transaction. 
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10. A system adapted to effect the performance of a payment card transaction according 
to claim 8 or claim 9, wherein the means for submitting created transaction records is 
suitably adapted to submit the second transaction record for processing as a converted 
payment transaction. 

11. A system adapted to effect the performance of a payment card transaction according 
to anyone of claims 8 to 10, further comprising means for creating a third payment card 
transaction record between the second cardholder and the second merchant for an 
amount in the first currency, which is the negative equivalent of the first amount and 
submitting the third transaction for payment processing. 

12.. A system adapted to effect the performance of a payment card transaction according 
to claim 11, wherein the means for submitting created "transaction records is suitably 
adapted to submit the third transaction record for processing as an unconverted payment 
transaction. 

13. A system adapted to effect the performance of a payment card transaction according 
to anyone of claims 8 to 12, further comprising means for detemiining whether a 
transaction is a dynamic currency convertible transaction prior to performing the Steps 
of creating the one or more transaction records. 

14. A system adapted to effect the performance of a payment card transaction according 
to anyone of claims 8 to 13, wherein the system comprises a payment card terminal. 

15. A system adapted to effect the performance of a payment card transaction according 
to anyone of claims 8 to 13, wherein the system comprises an intermediate or other host 
computer system adapted to receive payment transaction records from a payment card 
terminal or other device and route them for processing as either converted or 
unconverted transactions. 
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This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



